- Aplicaciones
Videos:
https://open.fing.edu.uy/courses/fsi/21/
https://open.fing.edu.uy/courses/fsi/22/
https://open.fing.edu.uy/courses/fsi/23/
https://open.fing.edu.uy/courses/fsi/24/
https://open.fing.edu.uy/courses/fsi/25/
https://open.fing.edu.uy/courses/fsi/26/
https://open.fing.edu.uy/courses/fsi/27/
Diapositivas:
[[aplicaciones_introduccion.pdf]]
[[aplicaciones_diseno_seguro.pdf]]
[[aplicaciones_riesgos.pdf]]
[[aplicaciones_modelado_amenzas.pdf]]
[[aplicaciones_autenticacion.pdf]]
[[aplicaciones_sesiones_web.pdf]]
[[aplicaciones_owasp_top_ten.pdf]]
Introducción
Seguridad en Aplicaciones
Introducción
En una máquina stand-alone, estamos en control de los componentes de software que hacen entrada al sistema. El software es seguro si puede manejar entradas intencionalmente malformadas. Analizaremos las causas generales de las vulnerabilidades en el software y propondremos pautas para mitigar los problemas.
Seguridad y Confiabilidad
- La seguridad del software está relacionada a la calidad y confiabilidad del software.
- La confiabilidad está vinculada a las fallas accidentales.
- Para hacer el software más confiable, se testea con patrones de uso típicos. En el contexto de seguridad, el atacante selecciona la distribución de las entradas.
Causas Básicas #parcial
Presentar las causas básicas que llevan a fallas de seguridad del software:
- Números y caracteres
- Representaciones canónicas
- Manejo de memoria
- Datos y código
- Condiciones de carrera (Race Conditions)
Taxonomía de un Malware #parcial
Malware: Malicious software.
-> Un bug no es malware si no hay mala intención.
- Hay diferentes tipos:
- Virus: Es un pedazo de código que se replica automáticamente, anexado a otro. Infecta un programa insertándose a sí mismo en otros programas (infectando).
- Gusano (Worm): Es un programa que se replica, pero no infecta.
- Caballo de Troya (Trojan horse): Programa con efectos laterales ocultos no especificados en su documentación y no previstos por el usuario.
- Bombas Lógicas: Se ejecuta únicamente cuando una condición específica se cumple.
- Backdoor: Permite (de forma intencional) acceso no autorizado a computadoras comprometidas.
- Exploit: Explota una falla de software para ganar acceso no autorizado.
- Rootkit: Software que se oculta de forma activa.
- HackTool: Herramientas de explotación, ataque y escaneo.
- Spyware: Software que invade la privacidad del usuario.
Codificaciones: Caracteres y Números
- Muchos defectos del software se deben a malas abstracciones.
- Problemas de este tipo relevantes para la seguridad pueden encontrarse con conceptos elementales como caracteres y enteros.
- Las descripciones de esos problemas se refieren a la forma en que dichos caracteres y enteros están representados en memoria.
Codificaciones
- Hay muchas, dependen del contexto:
- URL Encoding
- UTF-8 encoding
- ISO8859-1, Windows-1252, etc.
- Cada una expresa una abstracción.
Caracteres (codificación UTF-8)
-
Ejemplo de problema: Una aplicación debería dar a los usuarios acceso al subdirectorio A/B/C. Los usuarios ingresan el archivo como entrada. El path del archivo se construye como A/B/C/entrada. Podrían escalar en el árbol de directorios usando
../.- Acceso a los passwords:
../../../../etc/passwd. - Como contramedida, el desarrollador hace alguna validación de la entrada. Filtra la combinación
../.
- Acceso a los passwords:
-
La codificación UTF-8 se define para usar Unicode en sistemas que fueron diseñados para ASCII (RFC 2259). Los chars ASCII son representados por los bytes ASCII (0x00 - 0x7F).
-
Ejemplo: el signo © es U00A9, en UTF-8 se escribe como 0xC2 0xA9. Por ese motivo, un único carácter puede tener distinta representación: en el caso de '/': 1 byte – 2F, 2 byte – C0 AF, 3 byte – E0 80 AF.
URL Encoding
- Usa codificación “porcentaje”:
- pct-encoded = "%" HEXDIG HEXDIG
- {IP}/scripts/..%25%32%66../winnt/system32/
- %25%32%66 == %2F
- %2F = ?
- A veces el hecho de realizar una lectura e interpretación de los caracteres cambia el significado.
Overflow de Enteros
- Son representados como cadenas binarias de largo fijo (precisión).
- Los lenguajes de programación tienen enteros con signo o sin signo, cortos, largos, etc.
- Comparación entre una variable size con signo y size_t sin signo:
- if (size < sizeof(buf))
- Si size es negativo y el compilador lo “castea” con signo y size_t sin signo puede dar overflow. También se puede acortar un valor: Integer truncation.
- Lección:
- Declarar todos los enteros como sin signo a no ser que se necesiten enteros negativos.
- Tomar en cuenta warnings del compilador.
Arreglos
- Los índices de los arreglos utilizan aritmética de enteros.
- Si no se chequea que el resultado esté entre los valores permitidos, se va a asignar memoria fuera del arreglo.
- Por lo tanto, se deberían verificar los índices del arreglo siempre.
Representaciones Canónicas
- Los nombres (identidades, identificadores) se usan ampliamente como abstracción.
- Cuando una entidad tiene más de un nombre o un nombre con varias representaciones hay problemas.
- Lección:
- No confiar en los nombres recibidos del usuario, convertirlos a la representación estándar usada.
- No hacer decisiones basado en nombres a nivel de la aplicación sino utilizar al SO para ello.
Manejo de Memoria
- El runtime stack usando las direcciones de memoria más alta. Contiene los stack frames del proceso que se está ejecutando en el call stack. Un stack frame contiene info como direcciones de retorno, variables locales y argumentos.
- El heap comienza desde las direcciones más bajas.
Buffer Overruns #parcial
- Si el valor asignado a una variable excede el tamaño del buffer asignado, ocurre un buffer overrun (overflow).
- Los lugares de memoria no asignados a esta variable son sobreescritos.
- Así pueden escribirse los valores de otras variables.
- Han sido el origen de vulnerabilidades de seguridad desde hace un tiempo.
- Ejemplos:
- Bug del finger (worm de 1988) – buffer overrun en el demonio de finger.
- Heap buffer overflow in the TFTP protocol handler in cURL 7.19.4 to 7.65.3 (CVE-2019-5482).
- TRENDnet ProView Wireless camera TV-IP512WN 1.0R 1.0.4 is vulnerable to an unauthenticated stack-based buffer overflow in handling RTSP packets (CVE-2020-12763).
- Ejemplos:
Stack Overruns #parcial
- Los ataques de buffer overrun en el call stack se conocen como stack overruns.
Mitigación: stacks no ejecutables y “Canarios” #parcial
- Hay arquitecturas con stack no ejecutable. El software que lo necesite, no funcionará más.
- Intentos de cambiar la dirección de retorno pueden detectarse mediante el uso de “canarios” justo antes de dicha dirección.
Heap Overruns
- Otros ataques de overrun son más difundidos.
- El heap es el área de memoria asignada dinámicamente por la aplicación.
- Para tomar control de la ejecución, un atacante debe sobreescribir algún parámetro que influencie en el control o el flujo de datos.
- Ataca los punteros a funciones.
Confusión de Tipos
- Los programas escritos en un lenguaje type safe no pueden acceder a memoria de forma inapropiada.
- Un ataque de confusión de tipos manipula la estructura de punteros para que un tipo con un tag de clase distinta acceda al mismo lugar.
- Son tipos de ataques raros, pero ocurren.
Datos y Código
- Pueden ser importantes abstracciones al valorar la seguridad de un sistema.
- Cuando la entrada se toma y los datos se ejecutan, se rompe la abstracción y los ataques se hacen posibles.
Inserción de SQL
- SQL es sumamente usado para hacer consultas a BD.
- Las aplicaciones pueden procesar consultas SQL para acceder una BD desde una página web.
- Tip! No tratar de adivinar cuáles entradas están mal. Definir solamente las que son aceptadas, p.ej., usando regex.
Condiciones de Carrera #parcial
- Pueden ocurrir cuando múltiples procesos acceden datos compartidos (archivos, memoria).
- El resultado depende de la secuencia de acceso a dichos datos.
- Este problema se conoce en la literatura como TOCTTOU (time of check to time of use).
Categorias
Pueden dividirse en 2 categorías dependiendo de quién causa la interferencia.
- Por procesos no confiables, se denominan problemas de secuencia.
Son condiciones causadas por procesos que se meten dentro de la ejecución del nuestro. - Por procesos “confiables”, denominados problemas de locking.
Son condiciones causadas por procesos ejecutando el “mismo” programa.
Problemas de secuencia:
En general, debe verificarse el código por cualquier par de operaciones que puedan fallar si se ejecuta código arbitrario entre ellas. Notar que cargar, modificar y salvar una variable compartida no es un proceso atómico. Problemas característicos: archivos temporales.
Problemas de locking:
Hay situaciones en las cuales un programa debe asegurar que tiene derechos exclusivos sobre algún recurso. Cualquier sistema que haga locking debe lidiar con los problemas estándar de los locks (deadlocks, livelocks, etc.). Típicamente en Unix se utiliza la existencia de un archivo como lock, por ser portable.
Lección
Una transacción atómica es una abstracción de una operación que debería ejecutarse como una unidad.
Defensas
Debemos tratar de identificar patrones generales. En el caso de software inseguro, el patrón que se repite es el de abstracciones de programación como variable, array, integer. Los problemas de la seguridad en el software pueden ser direccionados en la arquitectura del procesador, lenguajes de programación, etc.
Prevención: Hardware
Muchos ataques de buffer overflow sobre-escriben información de control. Estos ataques pueden ser prevenidos mediante el uso de características del hardware para proteger la información de control. El procesador de Intel Itanium tiene un registro separado para la dirección de retorno.
Prevención: Type Safety
Podemos prevenir bugs en el software mediante el uso de un lenguaje de programación que nos prevenga de hacer errores. La seguridad en los tipos garantiza la ausencia de errores no atrapados. Ejemplos son Java y C#. Se puede garantizar mediante el chequeo estático y en tiempo de ejecución.
Prevención: Funciones Más Seguras
- Siendo un desarrollador programando en C/C++, se debe evitar escribir código susceptible a buffer overflow. C es tristemente célebre por las funciones de manejo de strings no seguras, como
strcpy,sprintf,gets. - Ejemplo:
char *strcpy (char *strDest, const char *strOrig).
Hay una excepción si el buffer de origen o destino son null. El resultado es indefinido si los strings no terminan en '\0'. - Es recomendable reemplazar las funciones por otras en las cuales se pueda especificar la cantidad de chars, ej:
strncpy,snprintf,fgets. - No erradican buffer overflow por sí solas.
Detección: Inspección de Código
La inspección de código manual es tediosa y tendiente a los errores por lo tanto es deseable alguna forma de automatización. Herramientas de este tipo exploran el código en búsqueda de errores potenciales. Es bueno para detectar tipos de problemas conocidos pero no garantiza que no hay vulnerabilidades.
Detección: Testing #parcial
El testeo es parte integral del desarrollo de software, normalmente será usada para demostrar la correctitud de la funcionalidad. En el testing de seguridad, la situación difiere algo dado que tenemos que mostrar la correctitud de la funcionalidad de seguridad. Esto implica tener alguna idea de las amenazas potenciales.
- Lección: No se necesita el código fuente para saber cómo se utiliza la memoria o para chequear si las entradas se verifican correctamente.
Data Mutation #parcial
Una técnica usada es la de Data Mutation. Esto envía entradas mal formadas a las interfaces de los programas. Se testea cómo se manejan las entradas inesperadas. El software puede caerse si se intenta crear un recurso que ya existe. Para los datos, los casos de test deben incluir los bordes, los tipos distintos, tamaños, etc.
Atenuación: Mínimo Privilegio
El principio de mínimo privilegio aplica dos veces. Al escribir código, ahorrar el requerir privilegios para ejecutar el código. Si este código se ve comprometido, el daño es limitado. También debe usarse nuevamente al instalar nuevos sistemas. No dar a los usuarios más derechos de acceso de los necesarios y no activar las opciones que no se necesitan.
- Lección: El software debe ser instalado de forma que los usuarios activen las características que necesitan, no al revés.
Reacción: Manteniéndose al Día
Cuando se descubre una vulnerabilidad, el código afectado debe arreglarse. La nueva versión debe ser testeada, se debe hacer el patch correspondiente y, por último, los usuarios deben instalarlo. Por ello, no son sólo los vendedores de software los que deben actuar, también lo debe hacer la comunidad de usuarios.
Ciclo de Vida de las Intrusiones
Diseño Seguro
- Minimizar el área de ataque.
- Establecer configuraciones por defecto seguras.
- Principio de menor privilegio.
- Principio de defensa en profundidad.
- Fallar de forma segura.
- No confiar completamente en servicios de terceros.
- Separación de responsabilidades.
- Evitar seguridad por oscuridad.
- Mantener la seguridad simple.
- Arreglar los problemas de seguridad correctamente.
Minimizar el Área de Ataque
Cada funcionalidad agrega una cierta cantidad de riesgo a la aplicación. Reducir el riesgo general mediante la reducción del área de ataque.
Establecer Seguridad por Defecto
Por defecto, la experiencia de uso de una aplicación debería ser segura. Debería ser el usuario quien pudiera habilitar funcionalidades adicionales (si tiene permiso).
Principio de Menor Privilegio
Las cuentas deben tener el menor privilegio requerido para realizar los procesos de negocio.
Defensa en Profundidad
Donde un control es razonable, más controles que piensan en los riesgos de diferentes formas son mejores. Los controles, cuando se usan en profundidad, pueden hacer que las vulnerabilidades graves sean extraordinariamente difíciles de explotar.
Fallar de Forma Segura
Las aplicaciones fallan regularmente en procesar transacciones por diversas razones. Fallar no debe dar al usuario privilegios adicionales, y no debería devolver información sensible no necesaria (ej., logs, DB queries).
No Confiar Completamente en Servicios de Terceros
Muchas aplicaciones usan servicios de terceros para obtener datos adicionales. El principio dice que no se debe confiar en estos servicios desde el punto de vista de la seguridad. Quiere decir que debe verificarse la validez de los datos enviados por el tercero y no asignarle altos niveles de privilegio a dichos servicios dentro de la aplicación.
Separación de Responsabilidades
Un control clave para evitar fraudes es separar las responsabilidades. Por ejemplo, alguien que solicita una nueva computadora no puede además firmar para habilitarlo, y no debería recibirla en forma personal. Los administradores no deberían ser usuarios de la aplicación. Deberían poder cambiar políticas de contraseñas, pero no comprar bienes como si fueran otros usuarios, por ejemplo.
Seguridad por Oscuridad
Es un control débil y casi siempre falla cuando es el único. La seguridad de la aplicación no debe depender de mantener un secreto como una URL oculta. No confundir con tener una clave, que es un secreto y debe mantenerse en secreto.
Mantener la Seguridad Simple
La superficie de ataque y la simplicidad van de la mano.
Arreglar Correctamente los Problemas de Seguridad
Luego de identificado un problema es importante crear un test para encontrar la causa. Si se han usado patrones de diseño, ese problema puede estar esparcido a lo largo del código. Escribir un test garantiza que no haya regresiones.
Gestión de Riesgos
Marco de Políticas
- Las aplicaciones seguras no solamente “suceden”.
- Son el resultado de una organización decidiendo que van a producir aplicaciones de esa forma.
- Para una aplicación segura, se requiere al menos:
- Una gerencia organizacional que conoce bien los problemas de seguridad que puedan tener.
- Una política de seguridad escrita derivada de estándares nacionales.
- Una metodología de desarrollo con adecuados checkpoints y actividades de seguridad.
- Procesos de Secure Release y Configuration Management.
- La mayoría de las organizaciones producen políticas de information security derivadas de la ISO 17799, o si es en USA, de COBIT, u ocasionalmente de ambos.
La Pregunta
Si les pregunto: ¿cómo defiendo mi aplicación?.... ¿de qué?
Gestión de Riesgos
- Al iniciar el diseño de una aplicación, es esencial aplicar análisis de riesgo.
- El método usado no es tan importante como realmente hacer un modelo estructurando el análisis de las posibles amenazas.
Terminología de Análisis de Riesgos Tradicional #parcial
- Activo: El objeto de los esfuerzos de protección. Puede ser definido como un componente del sistema, datos, etc.
- Riesgo: La probabilidad de que un activo sufra un evento con un impacto negativo.
- Amenaza: El actor o agente que es el origen del peligro. En general es un agente malicioso que efectúan ataques sobre la seguridad del sistema.
- Vulnerabilidad: Para que una amenaza sea efectiva, debe actuar sobre una vulnerabilidad. Es un defecto o debilidad en la seguridad de un sistema, su diseño, implementación, o controles internos. En el software, surgen de los defectos, y están en dos “sabores”:
- Fallas: problemas a nivel de diseño.
- Bugs: problemas a nivel de código fuente.
- Contramedidas o Salvaguardas: Los controles operacionales, de gestión, o técnicos realizados a un sistema de información. Tomados en conjunto protegen adecuadamente la confidencialidad, integridad, y disponibilidad del sistema. Para cada riesgo, pueden ponerse controles que previenen o detectan cuando se dispara el riesgo.
- Impacto: En la organización que usa el software, si el riesgo se materializara. Puede ser monetario, de imagen, violación de alguna ley, o de un SLA. Sin cuantificar un riesgo es difícil de mitigar.
- Probabilidad: Posibilidad que un evento dado se genere. Usualmente expresado como un porcentaje o simplemente Alto/Medio/Bajo.
¿Para qué calculo el riesgo?
- Para crear estrategias de mitigación.
- En definitiva, dónde poner los controles y cómo testearlos.
Cálculo de Riesgo
- Descomponer la aplicación: encontrar sus activos, funcionalidad y conectividad.
- Definir y clasificar los activos: clasificar los activos en tangibles e intangibles, y ponderarlos de acuerdo a su criticidad para el negocio.
- Explorar vulnerabilidades potenciales (técnicas, operacionales y de gestión).
- Explorar amenazas potenciales a través de un proceso de desarrollo de escenarios de amenaza o árboles de ataque.
- Desarrollar una visión realista de potenciales vectores de ataque desde la perspectiva del atacante.
Threat Modeling
Introducción
- Threat Modeling o también Análisis de riesgo de Arquitectura
- Ayuda a los diseñadores de sistemas a entender las amenazas de seguridad a las que se enfrentan sus sistemas.
- Permite desarrollar estrategias de mitigación para vulnerabilidades potenciales.
¿Qué queremos resolver con TM?
Las técnicas de TM usan los cuatro pasos siguientes:
- ¿Qué estamos construyendo?
- ¿Qué puede salir mal?
- ¿Qué vamos a hacer al respecto?
- ¿Hicimos un buen trabajo?
¿Qué estamos construyendo?
- Ejemplos de técnicas usadas:
- Diagramas de arquitectura
- Diagramas de flujo
- Clasificación de datos
- Juntar personas en diferentes roles con conocimiento técnico y en riesgos para acordar el framework a ser usado en el ejercicio de TM.
¿Qué puede salir mal?
- Esta es una actividad de “investigación” en la cual se quieren encontrar las principales amenazas que aplican a nuestra aplicación.
- Diversas formas:
- Brainstorming
- Usando estructuras que nos ayuden
- STRIDE, Kill chains, CAPEC, etc.
¿Qué vamos a hacer al respecto?
- Esta fase transforma lo encontrado en acciones específicas:
- Cambio en diagramas
- Creación de reportes de bugs
- Nuevos requerimientos
- Nuevas user stories al backlog
¿Hicimos un buen trabajo?
- Finalmente, se hace una actividad retrospectiva sobre el trabajo realizado para verificar calidad, viabilidad, progreso y/o planificación.
El proceso
- Puede ser informal usando Kanban o Post-its en la pared.
- El esfuerzo, trabajo y tiempos invertidos en TM se relacionan al proceso de ingeniería que se está usando.
- Puede ser usada independientemente del proceso de desarrollo (Agile, Waterfall, etc).
Técnicas de TM
- Cyber Kill Chain
- MITRE ATT&CK
- STRIDE
- Common Attack Pattern Enumeration and Classification (CAPEC™)
- Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) (CMU)
Cyber Kill Chain
- Acceso Inicial
- Ejecución
- Persistencia
- Escalada de Privilegios
- Evasión de defensas
- Acceso a credenciales
- Descubrimiento
- Movimiento lateral
- Recolección
- Command and control
- Exfiltración
- Impacto
STRIDE #parcial
- Usando el Proceso de Modelado de Amenaza de Microsoft (STRIDE)
- Ejecutando modelado de riesgo de amenazas:
- Flujo del Modelo de Amenaza
- Identificar Objetivos de Seguridad
- Visión General de la Aplicación
- Descomponer la aplicación
- Documentar las amenazas conocidas
Categorías STRIDE:
- Spoofing of user identity (Impersonar)
- Tampering (Falsificación, alteración)
- Repudiation (Repudio)
- Information disclosure (privacy breach or data leak) (filtrado de información)
- Denial of Service (DoS, Denegación de servicio)
- Elevation of privilege (Elevación de privilegios)
Impersonar
- Amenaza que apunta a acceder ilegalmente a las credenciales de otro usuario, como nombre de usuario y clave.
- Control asociado: autenticación.
- Mitigación: autenticación apropiada, proteger datos secretos, no guardar secretos.
Falsificar
- Amenaza que apunta a cambiar/modificar datos persistentes y la alteración de data en tránsito entre dos computadores.
- Control asociado: Integridad.
- Mitigación: autenticación apropiada, hashes, MACs, firmas digitales, protocolos resistentes.
Repudio
- Apunta a realizar operaciones ilegales en un sistema que no tiene la habilidad de tracear las operaciones prohibidas.
- Control asociado: no repudio.
- Mitigación: firmas digitales, timestamps, caminos de auditoría.
Filtrado de información
- Leer un archivo o recurso del cual no se tiene acceso, o leer datos en tránsito.
- Control asociado: confidencialidad.
- Mitigación: autorización, protocolos de privacidad mejorada, encriptación, proteger secretos.
Denegación de servicio #parcial
- Enfocada a denegar el acceso a usuarios válidos, como por ejemplo tener un servicio web.
- Control asociado: disponibilidad.
- Mitigación: filtrado, autenticación y autorización apropiadas, regulación, QoS.
Elevación de Privilegios
- Obtener acceso privilegiado a recursos para ganar acceso no autorizado a información o comprometer un sistema.
- Control asociado: autorización.
- Mitigación: ejecutar siempre con mínimos privilegios.
Controles de seguridad
- Deben identificarse para prevenir el impacto de las amenazas.
- Al realizar la revisión de código (y testing), debe verificarse que están en el lugar apropiado.
- Y que son invocados en los lugares que corresponde.
Control: autenticación
- Asegurar todas las conexiones internas y externas (usuarios y entidades).
- Asegurar que las credenciales de autenticación no atraviesen los cables en texto plano.
- Asegurar que puertas traseras de desarrollo/debug no estén presentes en el código de producción.
Control: autorización
- Asegurar que la aplicación ha definido claramente los tipos de usuarios y los derechos de estos usuarios.
- Asegurar que la autorización se verifica en cada pedido.
- Asegurar que la actitud de mínimo privilegio está en operación.
Control: Validación de entradas/datos
- Asegurar que existe un mecanismo de validación.
- Asegurar que todos los datos de un formulario/pantalla son validados.
- Regla de Oro: toda entrada externa, no importa lo que sea, es examinada y validada.
Control: manejo de errores/filtración de información
- Asegurar que las excepciones y otras condiciones de error se manejan de forma adecuada.
- Examinar si la aplicación audita las acciones tomadas en nombre del cliente.
- Tanto autenticación exitosa como no son registradas.
Control: criptografía
- Asegurar que no se transmiten datos sensibles en claro, tanto interna como externamente.
- Asegurar que se implementen métodos criptográficos conocidos.
DREAD: el modelo de clasificación de riesgos
- Factores de riesgo técnico: Damage (Daño) y Affected Users (usuarios afectados).
- Facilidad de explotación: Reproducibilidad, explotabilidad, discoverability.
- Del 1 al 10.
Autenticación Web
Introducción
- Necesaria para identificar los potenciales usuarios de las aplicaciones.
- Varias técnicas, generalmente conocidas.
- La mayoría de los entornos de desarrollo contemplan alguna de estas formas.
- Posibles problemas.
Autenticación
- Juntar una identidad del sistema a un usuario individual mediante el uso de una credencial.
- Proveer controles de autenticación razonables dados los riesgos en la aplicación.
- Negar el acceso a los atacantes que usan varios métodos para atacar el sistema de autenticación.
Técnicas comunes de autenticación web
- HTTP Basic y Digest (DAA).
- Basada en formularios.
- Basada en certificados.
- “Fuerte”.
- Federada (+SSO).
- FIDO.
Autenticación Basic y Digest
- Basic: Envía las credenciales en texto claro, codificadas en Base64. No debería usarse a no ser combinada con SSL.
- Digest HTTP: Usa un mecanismo de challenge-response, que es razonablemente seguro para aplicaciones de bajo costo. Está atado a MD5.
Problemas de Basic y Digest
Las razones en contra del uso de estos tipos de autenticación son:
- Transmisión insegura de las credenciales.
- Ambas formas de autenticación son pasibles de ataques de replay y man-in-the-middle.
- Ambas requieren TLS para proveer algún tipo de confidencialidad e integridad.
- Interfaz de usuario primitiva.
Usando Formularios
- Provee al diseñador de la aplicación mayor control sobre la interfaz hacia el usuario y los datos, por ello se utiliza ampliamente.
- Disponible y bien soportada por múltiples plataformas.
Problemas de los formularios
- Ataques de replay.
- Man-in-the-middle.
- Credenciales en texto claro si no se usa sobre HTTPS.
- Ataques de engaños (phishing).
- Débil control de passwords.
Certificados #parcial
- Está ampliamente implementada en varios servidores de aplicación y web.
- El sitio web genera certificados (o intenta confiar en certificados generados externamente).
- Los certificados públicos se cargan en la base de autenticación del servidor web.
- Se comparan con los ofrecidos en conexiones recibidas de navegadores.
- Si el certificado coincide, el usuario se autentica.
Problemas con los certificados #parcial
- Muchos usuarios comparten sus PCs y necesitan llevar sus certificados con ellos.
- El manejo de certificados en un navegador no es trivial en muchos casos.
- Certificados de revocación con certificados emitidos por nosotros mismos es casi imposible en redes externas.
- La confianza en servidores con certificados “privados” requiere que el usuario final tome decisiones de confianza sobre la CA root.
Autenticación “fuerte”
- Puede proporcionar un nivel más alto de seguridad que usuario y password solamente.
- Ejemplos de esto serían: Biometrics, One-Time password, Challenge-Response, SMS Challenge-Response, Transaction Signing.
Problemas de estos tipos de autenticación
- La mayoría de los frameworks de aplicación son difíciles de integrar con los mecanismos de autenticación fuertes, con la posible excepción de certificados, presente en J2EE y .NET.
- Debemos integrar el código con un servidor de autenticación, e implícitamente confiar en los resultados.
- La mayoría de las organizaciones ven estos tipos de métodos como “costosos”, para los riesgos que podrían enfrentar.
Autenticación federada #parcial
- Permite hacer outsourcing de la base de usuarios a un tercero, para tener varios sitios con single-signon.
- Ventajas:
- Reduce la cantidad total de credenciales que los usuarios deben recordar.
- Puede ser apropiada cuando los sitios son parte de una alianza de ventas o comercio grande.
- Permite proveer servicios personalizados a usuarios que de otra forma serían anónimos.
- No debería usarse, a no ser que:
- Se confíe en el proveedor de autenticación.
- Los requerimientos de privacidad sean alcanzados por el proveedor de autenticación.
#parcial
- Ejemplos: SAML, de Liberty Alliance; Microsoft Passport/Live; OpenID, OAUTH.
El navegador y “Remember password”
- Los navegadores modernos ofrecen a los usuarios el manejo de múltiples credenciales guardándolos de forma insegura.
- Este es un riesgo particularmente grave para aplicaciones que contienen información sensible o financiera.
- ¿Cómo protegerse?
- Se puede enviar en el HTTP:
<form … AUTOCOMPLETE="off">para los campos del form.
Reset del password automático
- Son comunes en donde las organizaciones creen que necesitan evitar costos de mesas de ayuda para la autenticación.
- Desde la perspectiva del manejo de riesgo, la funcionalidad parece aceptable en varias circunstancias.
- Igualmente, dicha funcionalidad equivale a un mecanismo secundario, pero mucho más débil, de passwords.
- Se da por las preguntas asociadas.
Logout
- Todas las aplicaciones deberían tener un método de salir de la aplicación.
- Es particularmente vital para aplicaciones que contienen datos privados o pueden ser usadas para robo de identidad.
- Se debe asegurar además que el logout borre todas las cookies y variables asociadas a la sesión.
- También se puede incluir un texto que alerte al usuario sobre la historia en un PC compartido.
CAPTCHA
“Completely automated public Turing test to tell computers and humans apart”.
- Permiten a los diseñadores web bloquear a usuarios no humanos de registrarse con el sitio.
- La razón tradicional para implementar un CAPTCHA es de prevenir a los spammers de registrarse y polucionar la aplicación con spam.
Mejores prácticas
- La autenticación será tan fuerte como el proceso de gestión de usuarios.
- Usar la forma más apropiada de autenticación de acuerdo a la clasificación de activos:
- Por ejemplo, usuario y password sirven para sistemas de bajo valor, como blogs o foros, un SMS challenge-response puede servir para sistemas de e-commerce de bajo perfil (en 2005), mientras que transacciones firmadas sirven para sistemas de alto valor, bancos on-line, etc.
- Re-autenticar a los usuarios para transacciones de alto valor y acceso a áreas protegidas.
- Autenticar la transacción, no el usuario.
- Los phishers se basan en pobres esquemas de autenticación. El valor real de la seguridad en este caso sirve para identificar transacciones fraudulentas, no tanto por los usuarios (dado que se pueden perder/robar los usuarios y passwords).
- ¡Los passwords únicamente no sirven para sistemas de gran valor!
Sesiones Web
Introducción
Las aplicaciones “finas” de clientes guardan de forma innata datos locales. Por diseño, el protocolo HTTP no tiene estado, y no mantiene nativamente una conexión entre el navegador cliente y el software del servidor. Las aplicaciones web no triviales pueden requerir mantener un estado a lo largo de una sesión.
Esta es la principal desventaja de HTTP para la implementación de aplicaciones complejas. #parcial
Solución: Sesiones Web
¿Cómo se implementan? Algo compartido entre el servidor Web y el cliente:
- Cookies (RFC 6265: HTTP State Management Mechanism)
- URL Rewriting
Problemas #parcial
- Variables de sesión expuestas
- Falsificación
- Secuestro de sesiones
Variables de sesión expuestas
Algunos frameworks usan áreas compartidas en el disco del servidor web para guardar datos de sesión. Por ejemplo, PHP usa el /tmp en Unix y C:/windows/temp en Windows por defecto. Pueden comprometer a la aplicación si el servidor web se comparte o es comprometido.
Falsificando la sesión
Muchas aplicaciones web toman medidas en contra de intentos de adivinar claves. Es menos común para las aplicaciones web detectar muchos intentos de continuar sesiones basadas en adivinar identificadores de sesión. Los servidores de aplicación rara vez hacen logs o auditan dichos intentos.
“Secuestro” de la sesión #parcial
Si el identificador se transmite via un parámetro en la URL en vez de una cookie, los GETs pueden guardarse en la historia, el cache, etc. Usar pedidos mediante POST puede ayudar a aliviar este problema. Hay propuestas de usar la IP dentro de la asociación a las sesiones - ¿Qué pasa con NAT/Proxies?
Regeneración de tokens de la sesión #parcial
Para reducir el riesgo de secuestro de sesiones y ataques por fuerza bruta, el servidor HTTP puede sin esfuerzo expirar y regenerar los tokens. Esto decrece la ventana de oportunidad para un ataque por replay o fuerza bruta.
Usando tokens en acceso a páginas
Algunos tokens (nonces) pueden usarse en conjunción con tokens específicos de sesión para proveer medidas de autenticidad en pedidos de clientes. El cliente del otro lado de la sesión es el mismo que pidió la página en la misma sesión. Pueden guardarse en cookies o en las propias query strings, y deben ser completamente al azar.
Crear un mapeo entre el cliente y el token en el lado del servidor. Esta técnica debería incrementar la dificultad de usar fuerza bruta con los tokens de autenticación de la sesión.
Algoritmos criptográficos débiles en sesiones
Si se generan tokens predecibles, un atacante no necesita capturar las variables de sesión de los usuarios remotos. Puede simplemente adivinar algunos identificadores de sesión. Los tokens de sesión deben ser únicos, no predecibles, y resistentes a ingeniería reversa.
Captura del token de sesión
Si puede capturarse un token en tránsito, es posible hacer secuestro de dicha sesión. Es más probable que suceda si sólo usamos HTTP. Nunca debe transmitirse en texto claro. Usar otro token para áreas que requieran mayor nivel de seguridad.
Tokens de sesión al salir
Se debe invalidar el token y borrar el identificador de sesión al salir el usuario. En general, las cookies se asocian a la vida de la ventana del browser. En una máquina compartida, el identificador de sesión puede quedar en el navegador y ser utilizado por el próximo usuario.
Ataques de validación de la sesión
Como cualquier dato, la variable de sesión debe ser validada para asegurar que está de la forma correcta. Que no contiene caracteres no esperados, y es válida en la tabla de sesiones. Por ejemplo, usar bytes nulos para truncar objetos de sesión y debido a errores de codificación se comparaba el largo del string más corto.
Best practices
Usar un manejador de sesión robusto y bien conocido dentro de algún framework de aplicación. Siempre usar las versiones más actualizadas porque pueden contener bugs. Si se está en duda, no deberían tomarse riesgos y guardar la información sensible del estado en sesiones en el servidor.
Siempre guardar datos del lado del servidor. Los datos para tomar decisiones no críticas, como por ejemplo el lenguaje o el tema, pueden guardarse en datos en el cliente. Los campos ocultos nunca deberían usarse para guardar información de estado sensible.
OWASP Top Ten
Modelo de riesgo usado por OWASP
Top 10
A1: Inyección
Evitar fallas de inyección #parcial
- Evitar el intérprete completamente.
- Utilizar una interfaz que soporte variables parametrizadas (Ej., declaraciones preparadas, o procedimientos almacenados).
- Decodificar y convertir todas las entradas del usuario a su forma mas simple antes de enviarlas al interprete.
- Siempre efectuar una validación ‘positiva’ de todas las entradas realizadas por el usuario.
- Seguir el principio de mínimo privilegio en las conexiones con bases de datos para reducir el impacto de una falla.
A2: Pérdida de Autenticación y Gestión de Sesiones
- Las funciones de la aplicación relacionadas a autenticación y gestión de sesiones son frecuentemente implementadas incorrectamente
- Permiten a los atacantes comprometer contraseñas, llaves, token de sesiones, o explotar otras fallas de implementación para asumir la identidad de otros usuarios.
Soy vulnerable?
- Permite ataques automatizados como la reutilización de credenciales conocidas, cuando el atacante posee una lista de pares de usuario y contraseña válidos.
- Permite ataques de fuerza bruta u otros ataques automatizados.
- Permite contraseñas por defecto, débiles o bien conocidas, como "Password1", "Contraseña1" o "admin/admin”.
Cómo prevenirlo?
- Implemente la autenticación multifactor (MFA).
- Evita ataques automatizados, de relleno de credenciales, fuerza bruta o re-uso de credenciales robadas.
- No incluya o implemente en su software credenciales por defecto, particularmente para administradores.
- Implemente un control contra contraseñas débiles, tal como verificar que la contraseña no esté incluida en la lista del top 10000 de peores contraseñas.
- Definir y aplicar políticas de contraseñas.
- Por ej: pautas de la sección 5.1.1 para Secretos Memorizados de la guía NIST 800-63 B's.
A3: Exposición de Datos Sensibles
- Sin un chequeo de control de acceso u otra protección, los atacantes pueden manipular parámetros para acceder a datos no autorizados.
- Aplicaciones o APIs no siempre verifican que el usuario está autorizado a trabajar con el recurso objetivo.
Soy vulnerable?
- Identificar las necesidades de protección de datos sensibles:
- Datos en tránsito y en almacenamiento.
- Contraseñas, números de tarjetas de crédito, registros médicos, información personal y datos sensibles del negocio requieren una protección adicional.
- Reglamentaciones, por ej, Reglamento General de Protección de Datos de la UE (GDPR), PCI Data Security Standard (PCI DSS).
- ¿Se transmite algún dato en texto claro? Esto se refiere a protocolos como HTTP, SMTP y FTP. No sólo externo, también todo el tráfico interno, por ejemplo, entre los balanceadores de carga, servidores web o sistemas backend.
- ¿Se utilizan algoritmos criptográficos antiguos o débiles?
- ¿Se utilizan claves criptográficas predeterminadas, se generan o reutilizan claves criptográficas débiles, o falta una gestión o rotación adecuada de las claves?
Cómo se previene?
- Clasificar los datos procesados, almacenados o transmitidos por el sistema.
- Aplicar los controles para cada clasificación.
- No almacene datos sensibles innecesariamente.
- Asegúrese de que se utilizan únicamente algoritmos y protocolos estándares y fuertes.
A4: Entidades Externas XML (XXE) #parcial
- Atacantes pueden explotar procesadores XML vulnerables si pueden cargar XMLs o incluir contenido hostil en un documento XML, explotando código vulnerable, dependencias o integraciones.
- De forma predeterminada, muchos procesadores XML no modernos permiten la especificación de una entidad externa, una URI que se referencia y evalúa durante el procesamiento XML.
Soy vulnerable? #parcial
- La aplicación acepta XML directamente o carga XML.
- especialmente de fuentes no confiables
- inserta datos no confiables en documentos XML
- SAML utiliza XML para afirmaciones de identidad, pudiendo ser vulnerable.
Cómo se previene? #parcial
- Utilizar formatos menos complejos como JSON.
- Actualice todos los procesadores y bibliotecas XML.
- Deshabilitar entidades externas de XML y procesamiento DTD en todos los analizadores sintácticos XML.
- Implementar validación de entrada positiva ("lista blanca"), filtrado, o sanitización para prevenir datos hostiles dentro de documentos, cabeceras o nodos XML.
A5: Pérdida de control de acceso
- El control de acceso aplica la política de modo que los usuarios no puedan actuar fuera de los permisos previstos.
- La explotación del Control de Acceso es una habilidad clave de los atacantes.
- El control de acceso es detectable utilizando medios manuales, o posiblemente a través de la automatización por la ausencia de controles de acceso en ciertos frameworks.
Soy vulnerable?
- Pasar por alto las comprobaciones de control de acceso modificando la URL, el estado interno de la aplicación o página HTML, o utilizando una herramienta personalizada de ataques a API.
- Permitir que la clave primaria se cambie a la de otro usuario, pudiendo ver o editar la cuenta de otra persona.
- Elevación de privilegios: actuar como un usuario sin iniciar sesión, o actuar como un administrador iniciando sesión como usuario.
- Manipulación de metadatos, como reproducir o manipular un token de control de acceso JWT (JSON Web Token), una cookie o un campo oculto para elevar los privilegios, o abusar de la invalidación de tokens JWT.
- La configuración incorrecta de CORS permite el acceso no autorizado a la API.
- Forzar la navegación a páginas autenticadas como un usuario no autenticado o a páginas privilegiadas como usuario estándar. Acceder a API con controles de acceso ausentes para verbos POST, PUT y DELETE.
Cómo se previene?
- El control de acceso solo es efectivo si es aplicado del lado del servidor o en la API.
- Con la excepción de los recursos públicos, denegar de forma predeterminada.
- Implemente los mecanismos de control de acceso una vez y reutilizarlo en toda la aplicación, incluyendo minimizar el control de acceso HTTP (CORS).
A6: Configuración de Seguridad Incorrecta
Los atacantes a menudo intentarán explotar defectos sin parchear o acceder a cuentas predeterminadas, páginas no utilizadas, archivos y directorios desprotegidos, etc. para obtener acceso o conocimiento no autorizado del sistema.
Soy vulnerable?
- Falta de hardening adecuado en el stack tecnológico, o permisos mal configurados en los servicios de la nube.
- Característica innecesarias habilitadas.
- Cuentas predeterminadas y sus contraseñas siguen activas.
- El manejo de errores revela trazas de la aplicación u otros mensajes de error demasiado informativos a los usuarios.
- Para sistemas actualizados, las nuevas funciones de seguridad se encuentran desactivadas o no se encuentran configuradas de forma segura.
- El servidor no envía cabezales de seguridad a los clientes o no se encuentran configurados con valores seguros.
- El software se encuentra desactualizado o posee vulnerabilidades (ver A9: 2017).
Cómo se previene?
- Un proceso de fortalecimiento reproducible que agilite y facilite la implementación de otro entorno que esté asegurado de manera apropiada.
- Una plataforma minimalista sin funcionalidades innecesarias, componentes, documentación o ejemplos. Elimine o no instale frameworks y funcionalidades no utilizadas.
- Un proceso para revisar y actualizar las configuraciones apropiadas para todas las advertencias de seguridad.
A7: XSS (Cross Site Scripting)
- Las fallas de XSS ocurren cada vez que una aplicación toma datos no confiables y los envía al navegador web sin una validación y codificación apropiada.
- XSS permite a los atacantes ejecutar secuencia de comandos cruzados (XSS) en el navegador de la victima los cuales pueden secuestrar las sesiones de usuario de usuario, destruir sitios web, o dirigir al usuario hacia un sitio malicioso.
Demostración #parcial
Cómo evitar fallas XSS
- Eliminar la Falla: No incluir entradas suministradas por el usuario en la pagina de salida.
- Defenderse de la Falla.
- Siempre efectuar una validación ‘positiva’ de todas las entradas realizadas por el usuario.
A8: Deserialización Insegura
La explotación de la deserialización es algo difícil, ya que los exploits como son distribuidos raramente funcionan sin cambios o ajustes en el código de exploit subyacente.
Soy vulnerable?
- Aplicaciones y APIs serán vulnerables si deserializan objetos hostiles o manipulados por un atacante.
- Dos tipos primarios de ataques:
- Ataques relacionados con la estructura de datos y objetos donde el atacante modifica la lógica de la aplicación o logra una ejecución remota de código si existen clases disponibles para la aplicación que pueden cambiar el comportamiento durante o después de la deserialización.
- Ataques típicos de manipulación de datos, como ataques relacionados con el control de acceso en los que se utilizan estructuras de datos existentes pero se modifica su contenido.
Cómo prevenirlo?
- No aceptar objetos serializados de fuentes no confiables o utilizar medios de serialización que sólo permitan tipos de datos primitivos.
- Si no es posible, considere uno o mas de los siguientes:
- Implementar verificaciones de integridad (por ej. firmas digitales) con el fin de detectar modificaciones no autorizadas.
- Cumplimiento estricto de verificaciones del tipo de los datos.
- Aislar el código que realiza la deserialización, de modo que ejecute en un entorno con los mínimos privilegios.
- Registrar excepciones y fallas en la deserialización, tales como cuando el tipo recibido no es el tipo esperado, o la deserialización lanza excepciones.
A9: Uso de Componentes con Vulnerabilidades Conocidas
- En teoría, debiera ser fácil distinguir si estas usando un componente o biblioteca vulnerable.
- Más aún, no todas las bibliotecas usan un sistema numérico de versiones entendible.
- No todas las vulnerabilidades son reportadas a un centro de intercambio fácil de buscar, Sitios como CVE y NVD se están volviendo fáciles de buscar.
Soy vulnerable?
- Para determinar si es vulnerable necesita buscar en estas bases de datos, así como también mantenerse al tanto de la lista de correos del proyecto.
- Debe evaluar cuidadosamente si es o no vulnerable revisando si su código utiliza la parte del componente vulnerable y si el fallo puede resultar en un impacto.
Cómo prevenirlo?
- Identificar todos los componentes y la versión que están ocupando, incluyendo dependencias.
- Revisar la seguridad del componente en bases de datos públicas, lista de correos del proyecto, y lista de correo de seguridad, y mantenerlos actualizados.
- Establecer políticas de seguridad que regulen el uso de componentes.
A10: Registro y Monitoreo Insuficientes
- Eventos auditables, tales como los inicios de sesión, fallos en el inicio de sesión, y transacciones de alto valor no son registrados.
- Advertencias y errores generan registros poco claros, inadecuados o ninguno en absoluto.
- Registros en aplicaciones o APIs no son monitoreados por actividad sospechosa.
- Registros son almacenados únicamente de forma local.
Cómo prevenirlo?
- Errores de inicio de sesión, de control de acceso y de validación de entradas se deben registrar con el contexto de usuario suficiente para identificar cuentas sospechosas o maliciosas.
- Transacciones de alto impacto deben de tener una pista de auditoría con controles de integridad para prevenir alteraciones o eliminaciones.
- Establecer monitoreo y alerta de actividades sospechosas.
Laboratorio #parcial
WebGoat
Sesiones Web
Se afecta mediante:
- Secuestro de sesión
- Fijación de sesión
- Falsificación de sesión
Referencia directa a objetos
Ocurre cuando un desarrollador expone una referencia a un objeto de implementación interno
Análisis de HTML y JS de una web
Permite:
- Obtener comentarios de chequeos que faltan.
- Verificar los chequeos que se realizan del lado del servidor.
Recordar que del lado del servidor siempre deberían haber validaciones, aunque haya del lado del cliente.
Inyección SQL
Caso:
SELECT * FROM 'tabla'
WHERE 'user' = '$_POST[usuario]' && 'pass' = '$_POST[pass]'
user: pepe' or '1'='1
pass: pepe' or '1'='1
o
user: pepe' or '1'='1';--
pass: no importa pq queda comentada esta parte
- Se soluciona validando las entradas.
- No es necesario tener siempre la salida de la consulta en una web, se puede hacer inyección 'blind'.
XSS
Una web es vulnerable si la cookie de sesión no tiene la bandera HTTP Only.
CSRF
Cross-Site Request Forgery (CSRF) is an attack that forces authenticated users to submit a request to a Web application against which they are currently authenticated. CSRF attacks exploit the trust a Web application has in an authenticated user.
Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user’s browser.
Ejemplo
This is the most simple CSRF attack to perform. For example you receive an e-mail with the following content:
<a href="http://bank.com/transfer?account_number_from=123456789&account_number_to=987654321&amount=100000">View my Pictures!</a>
If the user is still logged in to the website of bank.com this simple GET request will transfer money from one account to another. Of course in most cases the website might have multiple controls to approve the request.
Mitigación
- Uso del patrón de diseño "Synchronizer token pattern".
- Implementar controles basados en la interacción con el usuario.
- No usar GET para operaciones que cambian el estado de la APP.
- Usar Cookies con prefijos de host para identificar orígen de las request.
Vulnerabilidades en código C
Vulnerabilidades:
- lee de la entrada y no usa métodos seguros -> Buffer Overflow
- Un método es seguro si acepta un parámetro limitando la cantidad de caracteres a leer.
- concatena un path con un nombre de archivo leído de la entrada -> path traversal
- hace llamadas a system() con un string armado a partir de la entrada -> inyección
En el lab se hizo Bypass authentication a partir de un Buffer Overflow.